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REMARKS 

The specification has been amended above to insert the serial number of 
the referenced co-pending patent application on pages 1 and 7. 

The present application stands with its independent claims 1, 2, 3, 9, 15, 
21, 27, 28, 29 and 35 rejected under 35 U.S.C. §1 02(e) as being anticipated by 
the cited Borella et al. (Borella) patent. The dependent claims have been 
rejected under either 35 U.S.C. §1 02(e) as being anticipated by Borella, or under 
35 U.S.C. §1 03(a) over Borella in view of the cited Nessett et al. patent. For the 
reasons below, Borella is not believed to anticipate any of the independent 
claims. 

Although the title of Borella is "Method and System for Distributed Network 
Address Translation for Mobile Network Device," what Borella describes is not 
"Network Address Translation (NAT)" as that term is conventionally used in the 
art since no address translations are performed in the network . Rather what 
Borella teaches is address replacement at the client and teaches away (see, 
column 2, line 21 - column 3, line 58) from network address translation, which 
would be performed by a router or other device in the network . In Borella, a first 
device (e.g., a client, which in the described embodiment is a mobile device) 
requests a range of port numbers to use in packet communication. The second 
device (e.g., router) allocates to that client a range of port numbers independent 
of any protocol, and replies to the client telling it which port numbers have been 
allocated to it. The client then replaces the port number it would otherwise use 
by one of the port numbers allocated to it by the router. When the client 
thereafter wants sends a packet, that packet is encapsulated within another IP 
packet wherein in the internal IP packet, the source address is one of the global 
IP addresses allocated to it by the router and the destination address is the 
address on the Internet to which the packet is directed. In the external packet, 
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the source address is the actual local address of the client and the destination IP 
address is the local IP address of the router. When the encapsulated packet 
arrives at the router, it strips off the external packet and forwards the rest of the 
internal packet onto the Internet to the destination address indicated in the 
encapsulated packet. When the router receives a packet from the destination, 
the router consults its Port Allocation Protocol (PAP) table to determine which 
client has been allocated that global port number to which the packet is 
addressed, and forwards the packet accordingly to that client. Thus, for packets 
coming to the router from the client or for packets coming through the router and 
directed to the client, there is no "IP address and GPN translation." 

Since there is no translation of one address to another in the network , but 
merely replacement by the client in a packet it wants to send of its own source 
address with one of the global addresses supplied to it by the router and then 
encapsulation of the packet, what Borella discloses is not a network address 
translation as is used and claimed by applicants. 

Most significantly, Borella is incapable of accommodating an unspecified 
and unsupported protocol of which the router is unaware. In Borella, it is 
assumed that the client can abstractly request a port number from the router and 
that the router will supply a port that it can use. There is no suggestion or 
teaching of how the router would be able to properly function with an 
unsupported protocol. Specifically, with an unsupported protocol the router 
would need to know where in the packet the destination port number could be 
found. If the protocol being used to transmit a packet is supported, then the 
router knows that information. If it is an unsupported protocol, then the router 
has no way of knowing where within the packet that port number is located. 
Thus, if the router in Borella assumes in an incoming packet that the destination 
port number is located in same position as it is in a TCP packet, but the packet is 



16 



Serial No. 09/698978 



using, for example, an unsupported ISAKMP protocol for which the destination 
port number is located in a different location within the packet, the router will 
interpret the incorrect bits as being the port number. When the router in Borella 
consults then its Port Allocation Protocol table, it will be unable to find which 
client has been allocated to that port number, or alternatively, it will associate the 
packet with the wrong client. Thus, absent that location information, Borella is 
incapable of properly directing packets that use an unsupported protocol to the 
proper client. Thus, Borella is neither a "network address translator" nor is it 
capable of handling " a protocol not directly supported ", both of which each of the 
independent claims of the present invention require. 

Significantly, since in Borella the router does not perform a network 
address translation and cannot function with an unsupported protocol , there are 
no functions to be performed at the client, the mobile device in Borella, "of an 
Application Layer Gateway (ALG) that need to be implemented in association 
with the NAT'S translation " on either incoming or outgoing packets, as per 
independent claims 1 , 2, 27 and 28 of the present application. Furthermore, 
since the router in Borella doesn't perform any IP address and port translations 
on each outgoing packet from the client, which arrives at the router encapsulated 
within an outer packet and which inner packet is sent onto the network 
unchanged, no modification is performed on the packet at the client "so as to pre- 
compensate for the effects on the packets of the IP address and GPN 
translations," which translations are not made by the router. Similarly, since the 
router in Borella doesn't perform any IP address and port translations on a 
packet it receives from the network that is directed to the client, but merely 
forwards the packet unchanged to the client to which it has assigned the global 
port number included in the packet, the client, when it receives a packet doesn't 
modify it "so as to post-compensate for the effects on the packets of the IP 
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address and GPN translations," which translations are not made by the router. 
Thus, there is no need to perform any pre or post compensation on the 
encapsulated packet for any translations on that packet, which in any event, are 
not performed by the router in Borella, and cannot be performed in Borella for an 
unsupported protocol. Furthermore, since the router in Borella cannot function 
for an unsupported protocol because it will not know where within a packet the 
port number is located, the router can perform no compensation on packets 
arriving from or directed to the client. The recitations in independent claims 3, 9, 
15, 21 , 29 and 35 that recite "the packets being modified (at the client) so as to 
pre-compensate (or post-compensate) for the effects on the packets of the IP 
address and GPN translations" (by the NAT), in conjunction with "a protocol not 
directly supported by a network address translation" clearly distinguish these 
claims from Borella. 

In summary, Borella does not perform network address translation and in 
fact teaches away from it; is not capable of handling an unsupported protocol; 
does not teach performing the "functions of an ALG that need to be implemented 
in association with the NATs translations"; and does not modify at a client 
packets "so as to pre-compensate (or post compensate) for the effects on the 
packets of the IP address and GPN translations" (by a NAT). For these reasons, 
it is respectfully submitted that none of the independent claims are anticipated by 
or obvious over Borella and are therefore allowable. 

Inasmuch as the independent claims are believed to be allowable, each of 
the dependent claims thereon should also be allowable. 

In view of the foregoing, allowance of all the claims presently in the 
application and passage to issue of the subject application is respectfully 
requested. If the Examiner should feel that the application is not yet in a 
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condition for allowance and that a telephone interview would be useful, he 
invited to contact applicants' undersigned attorney at 973, 386-8252. 



Date: September ^-2004 

Docket Administrator (Room 3J-219) 
Lucent Technologies Inc. 
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